The present invention relates generally to computer systems. More particularly, the present invention relates to improved apparatuses and methods for processing software error messages in a computer system.
Software errors are errors that occur in the course of a program""s execution. In the prior art, there exist many methods for handling software errors when they occur. In one exemplary prior art method, software errors are handled by the computer operating system, which is endowed with programmed instructions to, for example, alert computer users of the problem encountered. By way of example, the operating system may detect that an out-of-memory condition has occurred and may communicate the error to the application program so that the application program may alert the user with an appropriate message using a generic error number such as xe2x80x9cError-28.xe2x80x9d By referencing the operating system user""s manual, for example, the user would then be able to interpret the meaning of the error number and perhaps take appropriate corrective actions.
In a more advanced prior art system, developers of computer applications provide application-specific error lists, each of which contains a multiplicity of error numbers and their associated messages. FIG. 1 illustrates an application error list 100, which is utilized by an application program 102 to interpret the error numbers to generate error messages. By referencing its error list, an application program can provide the user with error messages that are more relevant in the context of the application program in which the error occurs.
By way of example, the above error number xe2x80x9c28xe2x80x9d (out of memory) may be decoded by a word processing application program (via its error list) into a message stating xe2x80x9ctoo many characters in document.xe2x80x9d In a spreadsheet program, the same error number may be decoded (via the spreadsheet""s error list) into a message stating, for example, xe2x80x9ctoo many columns in spreadsheet.xe2x80x9d Similarly, a graphics application may process an out-of-memory error number or code into, for example, xe2x80x9ctoo many colors.xe2x80x9d These messages, being specific to their application program, provide more meaning to the user than the above-mentioned generic error number (xe2x80x9cError-28xe2x80x9d), i.e., the message that would have been generated had the operating system handled that error.
Application-specific error lists work well for application-centered, i.e., monolithic, applications. To elaborate, application-centered programs generally consist of data-handling codes to manage a predefined set of data types. A given monolithic document processing application program may contain codes to handle, for example, text and graphics. That monolithic application, however, would not be able to render and manipulate spreadsheet data or audio data that a user may wish to incorporate into the existing document at a later date. This is because application-centered programs cannot handle data types that are unknown to the program at the time of its creation.
The aforementioned limitation, among others, gives rise to a new type of software technology, i.e., one that is not application-centered. This new technology, referred herein as component-based architectures, allows different types of data to be rendered and manipulated within a given framework irrespective whether the framework is originally programmed to handle those types of data. In a component-based architecture, multiple data types may be embedded within the aforementioned framework, with each data type being rendered and manipulated by its own executable unit. Representative existing component-based architectures include OpenDoc(trademark) by Apple Computer, Inc. of Cupertino, Calif. and OLE(trademark) by Microsoft Corporation of Redmond, Wash. For further information regarding component-based architectures (e.g., OpenDoc(trademark) by Apple Computer, Inc. of Cupertino, Calif.) reference may be made to, for example, commonly-assigned, pending patent application U.S. Pat. Ser. No. 08/175,549, now U.S. Pat. No. 5,745,910, entitled xe2x80x9cFrame Structure Which Provides an Interface Between Parts of a Compound Documentxe2x80x9d which is hereby incorporated by reference.
The traditional approach to component-based architectures, however, may not enable the computer to provide a computer user with meaningful error messages when an error occurs in connection with a newly embedded data type. To facilitate a discussion of this problem, a compound document, representing one specific implementation of the aforementioned OpenDoc(trademark) component-based architecture, is discussed below. It should be borne in mind, however, that the component-based architecture is not limited to only document processing programs and may be extended to implement any type of computer-implemented task.
FIG. 2A shows a prior art component-based compound document framework 202 having various embedded component data and corresponding executable units. An executable unit generally comprises the binary code that is responsible for executing, manipulating and rendering the component data. In this example, the embedded component data comprise a text component 200, a graphics component 204, a spreadsheet component 206 and an arbitrary component 208, representing an arbitrary data type. Arbitrary component 208 is included herein to show that any type of arbitrary data may be embedded within framework 202 and utilized as long as it is provided with its own associated executable unit. Additional components may be embedded in framework 202 of FIG. 2A as desired.
There are further shown in FIG. 2A focus frames 212, 214, 216 and 218, corresponding to text component 200, graphics component 204, spreadsheet component 206 and arbitrary component 208 respectively. As the terms are used herein, xe2x80x9cframe in focusxe2x80x9d or xe2x80x9cfocus framexe2x80x9d denote the area within framework 202 that contains an embedded component. A component becomes the component in focus when a pointer is moved into its associated focus frame, followed by a selection command, e.g., by clicking on a mouse or other suitable user interface commands (i.e., while the executable unit for that component is currently executing).
In FIG. 2A, focus frame 212 contains embedded text component 200, which is rendered and manipulated by executable unit 224. Focus frame 214 contains embedded graphics component 204, which is rendered and manipulated by executable unit 233. Within graphics component 204, there is further embedded a color adjustment component 241 and associated focus frame 240. Color adjustment component 240 is rendered and manipulated by executable unit 227 and may be employed to, for example, modify the number of colors with which the graphics data within graphics component 204 is presented. Color adjustment component 241 is shown herein to illustrate that multiple levels of embedding are possible.
Focus frame 216 contains embedded spreadsheet component 206, which is rendered and manipulated by executable unit 235. Likewise, focus frame 218 contains embedded arbitrary component 208, which is rendered and manipulated by its associated executable unit 230.
In the prior art, framework 202 of FIG. 2A may also be provided with a comprehensive error list 209 designed to process the aforementioned generic error numbers when an error condition is encountered. However, the creator of framework 202 has no way to anticipate all the possible types of data, present and future, that a user may embed into a framework. Because of this, there may be situations in which a new component data that is unanticipated by the framework developer becomes embedded. If an error occurs while this new data type is manipulated, i.e., while the executable unit associated with that new data type is executing, the prior art error list may fail to provide an error message that is specific enough to be useful to the computer user. In this case, the user may be presented with the only error message the computer knows, e.g., the aforementioned error number message xe2x80x9cError-28.xe2x80x9d
In view of the foregoing, what is needed is improved methods and apparatus for handling software errors in a computer system, particularly one that implements a component-based architecture.
The invention relates, in one embodiment, to a method for processing a first error message to produce a second error message in a component-based architecture. The component-based architecture includes a framework which is associated with a first lookup handler and is capable of embedding a first component associated with a first executable unit for handling data of the first component. The method includes the step of generating a hierarchy of lookup handlers, the hierarchy including the first lookup handler and a second lookup handler associated with the first executable unit when the first component comes into focus.
Further, the method includes the step of processing the first error message through the hierarchy of lookup handlers to generate the second error message. Through the hierarchy, the first error message is first processed through the second lookup handler. If the second lookup handler is unable to process the first error message, the first error message is then processed through the first lookup handler. In this manner, the second error message is more specific to the first component than the first error message.
In yet another embodiment, the invention relates to an apparatus for processing a first error message in a computer implementing a component-based architecture. The component-based architecture includes a framework that is capable of embedding a first component associated with a first executable unit for handling data of the first component. The apparatus includes a first lookup handler associated with the framework that is capable of processing the first error message to produce a second error message.
The apparatus includes a second lookup handler associated with the first executable unit. The second lookup handler is capable of processing the first error message to produce a third error message. The apparatus further includes means for installing the first lookup handler and the second lookup handler into a lookup handler hierarchy, whereby the lookup handler hierarchy includes the first lookup handler and the second lookup handler when the first component is in focus and the lookup handler hierarchy is arranged such that the first error message is processed by the second lookup handler first. If the second lookup handler is unable to process the first error message, the first error message is then processed by the first lookup handler.
These and other features and advantages of the present invention will become apparent upon reading the following detailed descriptions and studying the various figures of the drawings.